본문으로 건너뛰기

오늘한 일

  • Rust 공부
  • Toss Next_채용 과제 찍먹

Rust 강의

Closure 인자로 전달

→ Closure는 동적인 크기를 가지므로
Box<Fn(i32, i32) -> i32> 로 전달

Fn 을 거대한 타입으로, (i32, i32)→i32 부분을 제네릭한 부분으로 생각하는게 좋아보인다


함수에 Closure로 전달하는 것의 이점

클로저는 인자로 넘겨주면 미리 정의된 함수만 사용해야하는 것이 아니다.
중간에 만들어진 함수(클로저)를 넘겨주어 동적으로 추가해 사용할 수 있다.


예제

fn math(a:i32, b:i32, op: Box<dyn Fn(i32, i32)->i32>) -> i32 {
op(a, b)
}

fn main(){
let add: Box<_> = Box::new(|a, b| a+b);
let mul: Box<_> = Box::new(|a, b| a*b);
let div: Box<_> = Box::new(|a, b| a/b);

println!("{:?}", math(2,2, add));
println!("{:?}", math(2,2, mul));
println!("{:?}", math(2,2, div));
}

dyn 키워드의 의미: dyn 자리에 다른 어떤 동적인 타입이 들어올 수 있다는 것을 의미
⇒ 여기선 add, mul, div가 이용되었다.


이 개념은 trait 에서 주로 사용되었으며 trait를 공유하는 여러 클래스의 사용 가능을 명시하는 느낌으로 시작되었다고 생각하면 된다.
→ 왜 trait가 아닌 Fn을 명시할 때도 dyn가 필요한지는 모르겠지만 일단 넘어가보자


Lifetime

소유권 개념: 기본적으로 생성된 변수의 lifetime은 해당 fn의 {} 안이다.


lifetime 문제상황

= 구조체 안에 소유권을 Borrow한 변수를 저장하는 경우


lifetime이 문제가 되는 이유

해당 값을 borrow해서 struct(Form)에 저장한 상태이다.
이 때 원본의 struct 구조체가 소유권을 소유한 scope(main)의 종료로 사라진다면?
의미상으로 해당 구조체에서 borrow한 변수(answer) 또한 반납되어야한다.

구조체는 남아있는데 구조체의 필드값이 없어지는 상황이 발생할 수 있으므로,
lifetime에 대해 컴파일러에게 보장해줘야하는 것이다.


문제해결

lifetime specifier로 해당 변수의 lifetime 컴파일러에게 보장
⇒ 올바른 코드

struct Form<'a>{
answer: &'a Answer
}

⇒ 이 struct가 존재하는 한, Answer 의 lifetime은 계속된다는 것을 알려준 것임


한계점

= 해당 문제가 일어나지 않을 것이라는 보장을 컴파일러에게 해주는 것
== 해당 문제가 일어나지 않게 할 수는 없다.

⇒ 이런 경우 소유권 개념에 주의하여 변수를 사용하도록 하자.


Rust 공식문서 1,2장 공부

1장

호기롭게 번역본을 만들자는 취지에서 필요한 내용들을 번역해서 Rustudy 레포에 올려놨다.

다른 챕터의 양을 보니 이건 못할 것 같다고 판단해서..
1장에서만 한 간단한 이벤트로 생각하기로 했다.ㅎㅎ

https://github.com/Self-Driven-Development/Rustudy/tree/main/%EC%9D%B4%ED%95%99%EB%A6%BC/1.%20%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0


2장

: 예제 코드를 다루는 것으로, 몰랐었던 개념을 간단하게 정리해봤다.

https://github.com/Self-Driven-Development/Rustudy/blob/main/%EC%9D%B4%ED%95%99%EB%A6%BC/2.%20Guessing%20Game/2%EC%9E%A5%20%EC%A0%95%EB%A6%AC.md


Toss Next 과제

: 내용은 유출하면 안되니까 느낀점 위주로 정리해보면,

내용

아는 부분이 많이 없었다.
안드로이드 개발을 시작했으나 UI 구성으로 XML 파일만 다루고 있어서 필요한 Kotlin 코드 로직을 구현할 수 없었다.

다음 화면으로 이동
Flutter의 ListView에 해당할 RecyclerView 다루기


느낀점

안드로이드 개발을 트라이하고는 있으나, Rust의 뒷전이 되어버린 것 같다.
진도를 너무 못나가고 있는게 아닌가 싶다.

내일 날을 잡고 UI 구현은 모두 마무리하는 걸로



마무리

: 공부방식을 노션 기입으로 바꾸면서 TIL을 쓰는 시간이 많이 줄었다.
그래서 앞으로 일기를 남기는 마무리란을 추가해볼까한다.


1__ 안드로이드 개발 비중을 Rust보다 높게 잡아가야겠다.
매일 5시간 정도는 투자해야 방학동안 뭔가 얻어갈 수 있지 않을까


2__ 철저하게 절약모드로 전환해야겠다.
돈은 없지만 일단 생각없이 쓰는 방식이 시험기간부터 다시 도졌었는데,
앞으로 나갈 돈도 많으니까 이제 다시 철저하게 나가는 구멍을 막아야겠다.

여행같이 쓸거면 확실하게 쓰고, 평소에 쓰는 카공 후 밥이라던가.. 밥 후 카공이라던가.. 이런 걸 틀어막아야겠다.


3__ 연애, 이성관계에 대해 조급하지 않나라는 피드백을 받았다.
하지만 나는 아무리 생각해도 조급해야하는게 맞는 것 같다.

항상 판단은 상황을 보고 하는거라고 생각하는데,
지금 나의 상황을 살펴보면

24살 마법사
⇒ 다른 사람들에 비해 경험적으로 뒤떨어진 상황이다.

사람과의 관계가 삶의 중요한 목표
⇒ 거창하게 목표랄 것까지 얘기할 필요는 없고 그냥 나는 살면서 사람들과 깊게 교류하는 걸 좋아한다.
나는 함께할 다른 사람이 필요한 사람이다.
그렇기에 그냥 수동적인 태도로 있고 싶진 않다. 더욱이 이렇게 경험적으로 뒤떨어진 상황에서 말이다.

적당히 외로운 상태 ⇒ 조급한 게 위험하다는 말은 대체로 맞는 것 같지만,
나는 지금 이성적으로 조급한 상태이지 정서적으로 조급한 상태가 아니다.
정서적으로 조급한 상태면 외로운 마음을 좋아하는 마음으로 착각해서 사귀는 등 건전하지 못한 선택을 할 수도 있지만
이성적으로만 조급한 상태이기 때문에 오히려 더 외로워지기 전에 기회를 만들어서 건강하게 사람과 관계를 맺을 수 있다고 생각한다.